fronted-backend protocol request, + "select for edit" request
От | M. Bastin |
---|---|
Тема | fronted-backend protocol request, + "select for edit" request |
Дата | |
Msg-id | a0610051cbd09f9c7968d@[213.224.114.176] обсуждение исходный текст |
Список | pgsql-novice |
I'm not sure if this is a good list to discuss this to make sure it are good ideas, but here I go. This is something that has kept bugging me with the frontend-backend protocols: For the RowDescription "T" and CopyOutResponse "H" messages I'd like to see a new property that would either contain the total number of bytes that is going to be sent, or the total number of rows. (Even only an estimation.) This would allow to implement clean progress bars in GUI clients. Now you can work around this by doing a COUNT(*) first, but this is a severe performance hit of course. Another annoyance is SELECT FOR UPDATE. There should also be something as SELECT FOR EDIT. The difference being that SELECT FOR EDIT wouldn't wait for the record to be unlocked but would fail to access it with an error message giving the user name of the user who's locking the record. (Then you can implement a dialog like "Sorry, this record is being edited by Joe. Please try to access it again later.") The problem with SELECT FOR UPDATE is that a human user can be editing and locking a record for 15 minutes or longer, during which other users who do a SELECT FOR UPDATE on the same record are frozen! There's a work-around with a tedious query to check whether a given record is locked prior to accessing it with SELECT FOR UPDATE, but if something like SELECT FOR EDIT was built in it would be so much easier and safer to use with future PostgreSQL upgrades! Thanks for any remarks or suggestions on these ideas, Marc
В списке pgsql-novice по дате отправления: